「你因為兩個原因來讀這本書：首先，你是位程式設計師。再者，你想成為一位更好的程式設計師」

取自: Clean Code (p.1)

前言

• 本系列文筆者嘗試將大神 Robert C. Martin (aka Uncle Bob，為敏捷軟體開發的初代推手之一、SOLID 設計原則提出者) 筆下三本經典大作濃縮，並以簡單的程式範例及補充，將 "Clean" 開發理念分享給各位讀者。接下來我們將依序導讀:
  • 無瑕的程式碼：敏捷軟體開發技巧守則 (Clean Code)
  • 無瑕的程式碼番外篇：專業程式設計師的生存之道 (The Clean Coder)
  • 無瑕的程式碼－整潔的軟體設計與架構篇 (Clean Architecture)

什麼是 Clean Architecture?

• 整潔軟體架構 (Clean Architecture) 的目的說穿了只有一個 － 最小化『建置和維護系統所需的人力』
  或者，我們也許能說，是為了最小化在整個軟體專案生命週期中，為了達到相對應業務需求所需投入的資源及成本 (包含資金、開發 & 維運人力、時間、運算資源...等)

  "The goal of software architecture is to minimize the human resources required to build and maintain the required system."

• 並不是為了一昧 解耦 (Decoupling) 而硬是為軟體畫分出無數的層次 (Layers) 和邊界 (Boundaries) 。這導致為了完成很簡單的需求，卻需要一併為沿途來回所經過的無數層次處理相對應的資料結構和通訊方法

  「實際上，最大的錯誤是 『過度架構 (Over-Architecture)』 。層數比我在這裡描述的還要多許多，這大大降低了團隊的生產力。整個工具被廢棄了，取而代之的是一個小團隊所編寫的一個可愛小應用程式」

• 也不是為了避免程式碼重複 (Duplicate) 而不考慮元件 (Component) 和類別 (Class) 的設計原則、依賴關係...等，直接將所看到的共用程式碼都提取到父類別或者某些介面。導致軟體的 可擴展性 (Extensibility) 下降

  「架構師往往會陷入一個陷阱 － 這個陷阱取決於對重複 (Duplication) 的恐懼」

• 除此之外，魔鬼也藏在實作細節中。你能想像團隊只要誤用某一種修飾子 (Access Modifier)，就有可能導致精心設計的架構遭到嚴重破壞嗎?

  "The net result is that if you ignore the packages (because they don’t provide
  any means of encapsulation and hiding), it doesn’t really matter which architectural style you’re aspiring to create."

• 而談到細節 (Details)，現代軟體工程提供了各式各樣的 Web & GUI、Databases、Frameworks，身為好的軟體架構師，又該如何考量呢?

  「優秀的架構師會小心地將細節從策略中分離出來，使策略與細節測底脫鉤，不以細節為依據。盡可能地延緩有關細節的決定」

最後以軟體架構與設計作為前言結尾，現代軟體工程隨著時間發展出了許多的架構...

• 水平橫向分層架構 (Horizontal Layer Architecture)
• 服務導向架構 (Service-oriented architecture)
• 六角形架構 (Hexagonal Architecture)
• C4 Model (Context, Containers, Components, and Code)
• 領域驅動設計 (Domain-Driven Design)
• 整潔的軟體架構 (Uncle Bob's Clean Architecture)
• ...

我們是否能歸納出一些共通的本質呢?

「本書就是要來講述這些規則的 － 那些永恆、不變的規則」

在後面的文章，我們會慢慢開始揭露這些如蜂巢、如洋蔥般的層層設計架構。在這之前我們先來思考......

為什麼要解耦? (Decoupling)

• 雖然過度追求解耦可能衍生過度設計 (Over-Design) 的問題，了解耦合性相關的議題仍然是學習軟體架構的重要入門課

• 軟體模組間的依賴性 (Dependency) 高會發生什麼? 直接看一個真實的例子:

  • 80年代某不願具名軟體公司的內部統計資料:
    工程人員的增長:
    
    同一時期的生產力:
    
    每行程式碼的平均成本:
    

• 我們可以看到

  • 隨產品釋出的次數與版本增加，參與專案的人員數、產值，以及開發成本之間的非線性關係
  • 即便工程師們持續加班，程式的產能幾乎沒有增加
  • 此時，專案重構的成本已經大於打掉重建了......

「當對程式碼的整潔程度或設計的結構沒有多少想法時，那你就會跟這條曲線一樣走到最終悲慘的結局」

取自: Clean Architecture (p.6)

為什麼要寫 Clean Code?

承上，甚至我們可以看到更嚴重的後果：

「我知道有一間公司在 80 年代後期開發了一個殺手級應用，但後來發行的週期開始拖長，程式裡的錯誤也無法在下次發行之前修復，程式載入的時間與崩潰機率也愈來愈長和高。不久，這家公司就倒閉了。我問他當時發生了什麼...」

「急於將產品上市，導致他們的程式碼變得一團糟，當他們加入愈來愈多的產品特點時，程式碼就變得愈來愈糟糕，一直到他們再也無法管理這團混亂。劣質的程式碼導致了這家公司的倒閉」

取自: Clean Code (p.3)

乾淨的代碼深入實作細節來探討如何透過編程風格與慣例，寫出好讀 (Readable)、易改、易維護的程式碼。接下來的導讀中，我們將從最基本的「命名」、「註解」、「縮排」開始探討好讀的程式碼應該要注重哪些細節。事實上，只要引入整齊一致的縮排和命名風格就能夠大大地增加程式碼的可讀性了

至於什麼叫做 「乾淨的程式碼」 ? 判別指標其實很單純，最小化它就是了:

「唯一有效的「程式品質」度量單位: 每分鐘罵髒話的次數 (WTFs/m) 」

什麼是 Clean Code?

上述指標純屬玩笑，讓我們援引各方大師的說法。更具體點來說...

「Clean Code 是可被原作者以外的開發者閱讀與增強的。它應當包含單元測試與驗收測試」

「減少重複、具有高度的表達力、並及早建立簡單抽象概念，這些對我而言，就是撰寫 Clean Code 的方法」

「當每個你看到的程式，執行結果都與你想得差不多，你會察覺到你正工作在 Clean Code 之上」

取自: Clean Code (pp.10-13)

為什麼要當 The Clean Coder?

最後是軟性議題。回歸開發者本身，面對種種的開發需求、甚至雜事、無效率的會議、何時該說 Yes or No?、專案時程與進度的控管、團隊協作開發......等，也是作為一位工程師非常重要的一部分。在此篇中不會提到任何程式碼，筆者可將其當作軟體工程師的職涯經驗談，至於書中內容是否適用於每種情況則見仁見智了

「學會作一位 Clean Coder 比學會寫出 Clean Code 還要難的多」

此外，書中作者對於 「流態區 (The Flow Zone) 」 的看法也是滿值得思考
究竟過於高度的專注是否真的有利於長期的程式開發呢?

「關於『高效率狀態』人們已經寫了很多，通常被稱之為『流態(flow)』。這是一種意識高度專注但思維視野卻會收斂到狹隘的狀態」

「他們會感到自己絕無錯誤、感到自己效率極高。然而這種意識狀態並非真的極為高效，這其實只是一種淺層冥想。為了追求所謂的速度，理性思考的能力會下降。你其實沒有顧及全域，你很可能會做出一些後來不得不摧毀的決策」

取自: The Clean Coder (p.95-96)

最後作者談到對 「會議」 的看法時，更是讓人會心一笑：

關於會議，有兩條真理:

1. 會議是必須的
2. 會議浪費了大量時間

取自: The Clean Coder (p.148)

未來我會持續、緩慢地反覆編輯並重構這一系列文章，為各位導讀這三本書的精隨。歡迎讀者每隔一段期間就來翻閱一下，或者一起交流~

後記

2024.02.11
讀這系列書並撰寫心得文，是碩畢剛出社會的第一年，當時還在寫 Web
後續轉職到了 IC 廠寫軟韌體兩年，看到的又更不一樣了.

再回頭看當初的文章，發現了許多可以再修正及勘誤的地方
今年預計再找時間，慢慢把重寫 Day01, Day02... 文章排進行事曆裡

2021.09.16
下筆的當下就開始極度後悔選這個主題了QQ... 要想一次把三本書中的內容都融會貫通並寫成系列文章發布，對筆者本身的程式底蘊和內功、職涯經驗有很高的要求。以我目前的程度，這系列文只能算是心得紀錄而已，對 "Clean" 理念的詮釋如有不足，敬請各位大神們包涵 ( _ _ )